//flamethrower .h file
UPROPERTY(BlueprintReadOnly, VisibleAnywhere)
UNiagaraComponent* FlameThrowerEffect = nullptr;
/** This variable is used to determine if a mod that gets held down needs its vfx on or off */
UPROPERTY(BlueprintReadOnly, ReplicatedUsing=OnRep_FireState)
/** Function called after Fire State gets replicated, simply calls the UpdateFireState() */
UFUNCTION()
virtual void OnRep_FireState();
/** Responsible for handling the logic for after the fire state is updated, mainly turning vfx on and off */
virtual void UpdateFiringState();
// if true then vfx is firing, else vfx is not firing
bool bFireState = true;
//flamethrower .cpp file
void AFlameThrowerMod::UpdateFiringState()
{
if (bFireState)
{
FlameThrowerEffect->Activate();
}
else
{
FlameThrowerEffect->Deactivate();
}
}
void AFlameThrowerMod::FireActiveMod(UCameraComponent* CameraComponent, UStaticMeshComponent* MuzzleLocation)
{
// this chunk of code is responsible for turning the vfx on and off on the client
OwningPlayer->UpdateFireState(this, true); // this function sets FireState to true on the server
FireState = true;
UpdateFiringState();
}
This logic once applied was easy to adapt where needed and apply the the logic of the laser as well as the railguns charge vfx. All while
maining the networked logic so that both client and server can see all the vfx we want them to. By that I mean some vfx we may
not want to bother with sending over the server and just do it locally. For example, most of the new vfx given to me by our vfx
artist have seperate muzzle vfx and projectile vfx. In most cases, except for the railgun, the muzzle vfx is not replicated
across to the other player since its not really something thats critical by any means and only adds to the visuals for the
player firing the weapon.